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A SYSTEM FOR RENDERING MULTIMEDIA MESSAGES BY 

PROVIDING, IN A MULTIMEDIA MESSAGE, URL FOR 
DOWNLOADABLE SOFTWARE TO A RECEIVING TERMINAL 

Field of the Invention 

5 The invention relates to adaptation of multimedia messages by a multimedia 

messaging service center (MMSC) and more specifically providing the MMSC that 
enables a receiving terminal to render multimedia messages in generally unsupported 
formats. 

Background of the Invention 

10 A problem in multimedia messaging services is that terminals have very 

different capabilities (supported media formats, maximum image resolution, 
maximum message size, etc.). This creates interoperability problems. To reduce this 
problem, multimedia messaging service centers (MMSC) can adapt messages to the 
specific terminal capabilities. These capabilities are obtained through UAProf or 

1 5 deduced from HTTP AVSP headers such as a User Agent header (UAHEADER) and 
Accept headers. However, there are cases where the MMSC cannot adapt without 
significantly deteriorating the quality of the content or it does not have the 
functionality to do so. An example of the first case is converting a video clip to an 
image (e.g. extracting the first frame of the video clip). An example of the second 

20 case is if the message contains an image in PNG format (not supported by the 

receiving terminal) and the MMSC cannot convert PNG to an image format supported 
by the terminal (e.g. converting PNG to GIF). In these cases, user experience is 
drastically reduced. 

In the current state of the art, the MMSC tries its best to adapt each media 
25 component to a format that is supported by the terminal (based on the reported 

capabilities). However, the MMSC transcoding capabilities maybe limited only to a 
small set of formats. For example, the Nokia MMSC can convert GIF to JPEG and 
video to JPEG but those are about the only image format conversions supported so 
far. When the message quality is reduced too much, the message can also be 
30 forwarded to an e-mail address or legacy terminal support (some Web server for 

messages). Nevertheless usability is significantly reduced at a receiving terminal (e.g. 
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when converting a video clip to a single image). For many other formats (PNG, 
PBM, etc.), the MMSC cannot perform the adaptation at all. Those components are 
still sent to the terminal if they fit within the multimedia messaging service message 
size restriction, but they may be unusable on the terminal side. 

5 Thus, it is desirable to increase interoperability between terminals by providing 

an easy way for terminals to render originally unsupported components of the 
multimedia messages. It is also desirable to improve the user experience by providing 
easy assurance that messages can be adapted and to avoid cases where the MMSC just 
sending an unsupported component (with which the terminal doesn't know what to 
10 do) or dropping it. It is further desirable to increase performance of already deployed 
mobile phones. 

Summary of the Invention 

The object of the present invention is to provide a system for rendering 
multimedia messages by providing a terminal-specific uniform resource locator 
15 (URL) for downloadable software to a receiving terminal. 

According to a first aspect of the present invention, a method for rendering 
multimedia messages comprises the steps of: providing a multimedia messaging 
service signal incorporating a further multimedia message signal (FMMS) indicative 
of a multimedia message and a terminal-specific uniform resource locator (URL) 
20 signal from a multimedia messaging service center to a receiving terminal, said URL 
signal providing an Internet server location of software obtainable by the receiving 
terminal; and providing the software to the receiving terminal for rendering the 
multimedia message by the receiving terminal. 

In further accord with the first aspect of the invention, the software is provided 
25 to the receiving terminal in response to a software request signal sent by the receiving 
terminal to the Internet server location provided by the URL signal; wherein the 
software request signal may be sent by the receiving terminal to the Internet server 
location provided by the URL signal automatically after receiving the multimedia 
messaging service signal incorporating the URL signal, or the software request signal 
30 may be sent by the receiving terminal to the Internet server location provided by the 
URL signal only after receiving a software request command from a user. 
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Still further according to the first aspect of the invention, after the step of 
providing the multimedia messaging service signal, the method further comprises the 
step of deciding whether additional software is needed to be installed in the receiving 
terminal for rendering originally unsupported components of a multimedia message 
5 signal by the receiving terminal; wherein said decision may be made by the user or 
said decision may be made automatically by the receiving terminal. 

Further still according to the first aspect of the invention, the method further 
comprises the step of rendering the further multimedia message signal indicative of 
the multimedia message by the receiving terminal, so that the multimedia message is 
1 0 perceptible by a user. 

In further accordance with the first aspect of the invention, prior to the step of 
providing the multimedia messaging service signal, the method further comprises the 
step of receiving and optionally storing the multimedia message signal by the 
multimedia messaging service center. 

15 Yet further still according to the first aspect of the invention, the method 

further comprises an optional step of providing a message notification signal to the 
receiving terminal by the multimedia messaging service center. 

According further to the first aspect of the invention, the method further 
comprises the step of providing a message retrieval request signal containing a 

20 terminal signal indicative of a terminal information and optionally a multipurpose 
internet mail extension (MIME) signal indicative of a terminal-specific MIME 
information to the multimedia messaging service center by the receiving terminal. 
Further, the message retrieval request signal may be sent in response to the message 
notification signal. Still further, the MIME information may be deduced by the 

25 multimedia messaging service center from the terminal information contained in the 
message retrieval request signal and from a software release information. Also 
further, a terminal signal indicative of a terminal information may be provided to the 
multimedia messaging service center during a registration process of a particular 
application, wherein the particular application may be a session initiation protocol 

30 (SIP) instant messaging or a SIP messaging session. Still also further, a terminal- 
specific multipurpose internet mail extension (MIME) information may be deduced 
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by the multimedia messaging service center from the terminal information and from a 
software release information. 

According still further to the first aspect of the invention, the method further 
comprises the step of evaluating by the multimedia messaging service center whether 
5 it is appropriate to adapt unsupported components of the MMS to meet the 

capabilities of the receiving terminal and identifying the URLs for terminal-specific 
additional software to render the unsupported components of the multimedia message 
signal based on the terminal and MIME signals using a database of the multimedia 
messaging service center. 

10 According still further to the first aspect of the invention, the method further 

comprises the step adapting by the multimedia messaging service center the 
appropriate unsupported components of the MMS to meet the capabilities of the 
receiving terminal. 

According to a second aspect of the invention, a system comprises a 
1 5 multimedia messaging service center, for providing a multimedia message service 
signal incorporating a further multimedia message signal indicative of a multimedia 
message and a terminal-specific uniform resource locator (URL) signal, said URL 
signal providing an internet location of downloadable software; and a receiving 
terminal responsive to the multimedia message service signal, for obtaining said 
20 software for rendering the multimedia message. 

According further to the second aspect of the invention, the multimedia 
messaging service center is further responsive to a multimedia message signal 
indicative of the multimedia message and to a message retrieval request signal 
containing a terminal signal indicative of a terminal information and optionally a 
25 multipurpose internet mail extensions (MIME) signal indicative of a terminal-specific 
MIME information. Also, the multimedia messaging service center may further 
provide a message notification signal to the receiving terminal. 

Further according to the second aspect of the invention, the receiving terminal 
is further responsive to a software request command by a user, provides a message 
30 retrieval request signal containing a terminal signal indicative of a terminal 

information and optionally a multipurpose internet mail extensions (MIME) signal 
indicative of a terminal-specific MIME information, provides a software request 
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signal to an Internet server, provides a URL image signal to the user, and renders the 
further multimedia message signal indicative of the multimedia message perceptible 
by the user. Also, the receiving terminal may be responsive to a message notification 
signal. 

5 Still further according to the second aspect of the invention, the system further 

comprises a sending terminal, for providing a multimedia message signal to the 
multimedia messaging service center. 

According to a third aspect of the invention, a multimedia messaging service 
center comprises a database for identifying uniform resource locators (URLs) of 

10 terminal-specific downloadable software; and means for providing a multimedia 
message service signal to a receiving terminal, incorporating a further multimedia 
message signal (FMMS) indicative of a multimedia message and a URL signal, said 
URL signal providing an internet server location of the terminal-specific 
downloadable software for rendering unsupported components of the FMMS by the 

1 5 receiving terminal. 

According to a fourth aspect of the invention, a receiving terminal, comprises 
means responsive to the multimedia message service signal, incorporating a further 
multimedia message signal ( FMMS) indicative of a multimedia message and a 
terminal-specific uniform resource locator (URL) signal, said URL signal providing 
20 an Internet server location of software obtainable by the receiving terminal; and 

means for sending a software request signal to the Internet server location provided 
by the URL signal. 

Brief Description of the Drawings 

For a fuller understanding of the nature and objects of the present invention, 
25 reference is made to the following detailed description taken in conjunction with the 
following drawings, in which: 

Figure 1 is a block diagram representing a system configuration, according to 
the present invention. 

Figure 2 is a flow chart illustrating a system performance, according to the 
30 present invention. 
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Best Mode for Carrying Out the Invention 

This invention is about having a multimedia messaging service center 
(MMSC) providing to a receiving terminal, in an adapted multimedia messaging 
service signal (MMSS), a uniform resource locator (URL) signal indicative of where 
5 to obtain media handling/decoding software that allows the receiving terminal to 
support the media content in the MMSS. The MMSC provides the URLs that are 
specific to the receiving terminal based on the terminal capabilities received (i.e. 
based on the terminal model and software release for instance) and possibly the 
multipurpose internet mail extension (MIME) types of originally unsupported 

10 components. For example, the video decoding software are different for a Nokia 

phone and an Ericsson phone, therefore, the URLs for these two phones are different. 
URL information is embedded in the MMSS and inserted .during the message 
adaptation processing. For that, the MMSC needs to have a database associating the 
URLs with media formats (MIME types) and phone types. Having these URLs, the 

15 user goes to those locations, downloads and installs the software, and finally renders 
the message components in the message that it previously could not handle. 

Figure 1 is a block diagram representing a system configuration, according to 
the present invention. A sending terminal 10 sends a multimedia message signal 
(MMS) 12 indicative of a multimedia message (MM) to a multimedia messaging 

20 service center (MMSC) 14. In the present invention, the multimedia message has a 
broad interpretation including, but not limited to, traditional multimedia messages 
(combination of multiple forms of media in the communication of information such as 
audio, video, text, graphics, etc), the Multimedia Messaging Service defined in Open 
Mobile Alliance (OMA), in 3GPP and 3GPP2, e-mails, instant messages (such but not 

25 limited to IETF SIMPLE, Wireless Village, OMA Instant Messaging and Presence 
Services (IMPS)), etc. In an extreme case, the multimedia message can be a response 
to a request to a Web server. Similarly, the MMSC has a broad interpretation 
including, but not limited to, an MMSC defined in OMA/3GPP Multimedia 
Messaging Service, an e-mail server, servers and proxies for Instant Messages, and 

30 Web servers. 

The MMSC 14 receives the MMS 12 and can store it. MMSC 14 may provide 
a message notification signal 16 to a receiving terminal (RT) 22 (such as a mobile 
telephone, a personal digital assistant or a computer) which notifies the receiving 
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terminal 22 and optionally a user 24 about the multimedia message. In certain 
instances (for example, e-mail) the MMSC 14 will not provide the message 
notification signal 16 to the receiving terminal 22 and therefore sending the message 
notification signal 16 is generally optional. In the case of e-mail, the terminal 22 or 
5 the user 24 typically verifies periodically for new messages at the MMSC 14. The 
receiving terminal 22 provides a message retrieval request signal (MRRS) 18 to the 
MMSC 14. The MRRS 18 could be in response to the message notification signal 16 
or it could be a stand-alone request, for example, for e-mail messages. The MRRS 18 
contains information about capabilities of the receiving terminal 22 (e.g. based on the 

10 terminal model and software release, UAProf or other means) and possibly 

multipurpose internet mail extension (MIME) types for the describing the supported 
media components. Note that if the MIME types are not provided, they often can be 
deduced from the terminal model and software release by the MMSC 14. The MMSC 
14 evaluates the content of the MMS 12 vs. the receiving terminal 22 and MIME 

1 5 information to determine whether each component of the multimedia message is 
supported by the receiving terminal 22 and if additional software in the receiving 
terminal 22 is required for rendering the originally unsupported components of the 
MMS 12. 

If the receiving terminal 22 fully supports all of the components of the MMS 
20 12, the MMSC 14 sends a multimedia messaging service signal (MMSS) 20 

containing the MMS 12 to the receiving terminal 22, and the latter renders the MMS 
12, and the rendered multimedia message 28 is perceived by the user 24. If, on the 
other hand the receiving terminal 22 does not support all of the components of the 
MMS 12, the MMSC 14 decides if it is more appropriate to adapt the unsupported 
25 components to the existing receiving terminal 22 capabilities (through quality 
reduction, image resolution reduction, format conversion, etc.), or to provide 
information to the receiving terminal 22 about the location of software that would 
allow it to support those components, or to do both (e.g. convert to a format that is not 
supported by the terminal, giving a better user experience compared to converting to a 
30 supported format, and for which software exists for the terminal to render it). The first 
case is what typically happens today. In the second case, the MMSC 14 uses its 
database 14a to identify one or more uniform resource locators (URLs) for the 
additional software needed to be installed in the receiving terminal 22 for rendering 
the originally unsupported components of the MMS 12. The database 14a can be 
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organized in many ways. One way is to provide it with USER- AGENT header 
(providing terminal model and software release) and MIME type and it returns the 
URL of the software available to render such MIME type for the terminal associated 
with the given USER- AGENT. The database 14a can return many URLs if for 
5 instance many software alternatives exist (e.g. from different vendors). Note that the 
terminal capability information can be contained not only in the MRRS 18 but can 
also come from other sources such as a user profile database which can be a part of 
the MMSC 14 (or external). The MMSS 20 sent by the MMSC 14 to the receiving 
terminal 22 contains both the adapted version of the MMS 12 (a further multimedia 
10 message signal, FMMS, indicative of the multimedia message) and a URL signal for 
each software needed to render the message. The location of the URL signal in the 
MMSS 20 is an implementation detail. It can be a part of a message text component 
(e.g. Info text) or it can be a part of a header. Note also that the MMSS 20 can contain 
many URLs per MIME type. 

15 Furthermore, a decision is made whether to download and install software to 

the receiving terminal 22 for rendering the originally unsupported components of the 
MMS 12. This decision can be made automatically by the receiving terminal 22 
followed by sending a software request signal 34 based on the software location 
information contained in the URL signal to an Internet server 32 and subsequently, 

20 receiving 36 and installing the requested software. This decision can be also made by 
the user 24 after analyzing a URL image signal 26 displayed by the receiving terminal 
22 or the download conditions provided by the Internet server 32 (e.g. cost of 
downloading the software). Especially, when multiple URLs are offered per MIME 
type, the user 24 decision is important as he can select the best software based on cost, 

25 memory footprint, reputation of the company providing the software, etc.. If the user 
24 decides to install the software, the user 24 sends a software request command 30 to 
the receiving terminal 22, followed by sending the software request signal 34 based 
on the software location information contained in the URL signal to the Internet 
server 32 and subsequently, receiving 36 and installing the requested software by the 

30 receiving terminal 22. The receiving terminal 22 renders the adapted version of MMS 
12 (FMMS) indicative of the multimedia message, generally comprising originally 
supported components, adapted components (per prior art), adapted components still 
unsupported (with URLs available), originally unsupported components (with URLs 
available), and possibly originally unsupported components (without URL). Thus, the 
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supported components of the multimedia message including originally supported and 
adapted components and originally unsupported components for which the additional 
software installed using URLs, are perceived by the user 24. 

Figure 1 illustrates only one scenario for implementation of a system 
5 described in the present invention. A number of variations and further developments 
are possible. For example, the MMSC 14 can have an extensive user profile database 
14a containing detailed information about the receiving terminal 22 capabilities and 
corresponding MIME information, so it can identify the URL information for the 
software needed to be installed in the receiving terminal 22 for rendering the 

10 originally unsupported components of the MMS 12. In that case the MMSS 20 

containing both the FMMS (adapted version of MMS 12) and the URL signal can, 
depending on the specific service protocol, be sent by the MMSC 14 to the receiving 
terminal 22 without previously sending the message notification signal 16 to the 
receiving terminal 22 and receiving the MRRS 18 from the receiving terminal 22, 

1 5 That would typically be the case in SIP Instant Messaging (IETF SIMPLE 

specification) where the terminal capabilities could be known from the registration of 
the terminal to its registrar. At registration, the terminal would provide USER- 
AGENT information in addition to other terminal capabilities. The SIP adaptation and 
inclusion of URLs could be performed in a SIP proxy which would perform the role 

20 of the MMSC 14 of Figure 1 . 

Figure 2 shows a flow chart further illustrating a system performance. In a 
method according to the present invention, in one possible scenario, in a first step 40, 
a sending terminal 10 sends the multimedia message signal (MMS) 12 indicative of a 
multimedia message (MM) to the multimedia messaging service center (MMSC) 14. 

25 In a next step 42, the MMSC 14 receives the MMS 12 and can store it In a next step 
44, the MMSC 14 provides the message notification signal 16 to the receiving 
terminal 22. Step 44 can be skipped in certain situations, for example, for e-mail 
messages. In a next step 46, the receiving terminal 22 provides the MRRS 18 
containing the terminal and MIME information to the MMSC 14. Again, depending 

30 on the specific service, this step can be skipped such as in the case of SIP Instant 
Messaging (for this service, this step of providing terminal capabilities can be 
achieved during the registration process). In a next step 48, MMSC 14 evaluates if it 
is appropriate to adapt the unsupported components (one or more) of the MMS 12 to 
meet the capabilities of the receiving terminal 22 and using its database 14a identifies 
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URLs to software, which if downloaded to the receiving terminal 22 will allow the 
unsupported components of the MMS 12 to be rendered by the receiving terminal 22. 
Based on evaluation of the step 48, in a next step 49, the MMSC 14 adapts the MMS 
12 by adapting the appropriate unsupported components of the MMS 12 transforming 
5 these components to meet capabilities of the receiving terminal 22. Said adapted 
MMS 12 is a further multimedia message signal (FMMS) indicative of the original 
multimedia message. The adaptation process can also include transforming 
unsupported components to formats still unsupported by the receiving terminal 22 but 
for which software is available for its proper rendering and for which URLs to such 

10 software exist. In a next step 50, it is ascertained by the MMSC 14 whether the 
receiving terminal 22 requires additional software for rendering the unsupported 
components of the FMMS. As long as no extra software is required, the MMSC 14 in 
a next step 52 sends the multimedia messaging service signal (MMSS) 20 containing 
the FMMS generated in the step 49 to the receiving terminal 22, and in a next step 

15 62, the receiving terminal 22 renders and presents 28 the FMMS and the multimedia 
message is perceived by the user 24. However, if it is ascertained by the MMSC 14 
that the receiving terminal 22 requires additional software for rendering the 
unsupported components of the FMMS, in a next step 54, the MMSC 14 sends the 
MMSS 20 containing the FMMS generated in the step 49 and the URL signal 

20 determined in the step 48 to the receiving terminal 22. In a next step 56, it is 

ascertained whether the additional software is wanted or needed to be installed in the 
receiving terminal 22 for rendering the unsupported components of the MMS 12. As 
long as that is not the case, in a next step 62, the receiving terminal 22 renders the 
supported components of the FMMS and information provided 28 by the supported 

25 components of the multimedia message is perceived by the user 24. If it is decided 

that additional software is required, in a next step 58, a request signal is provided on a 
line 34 from the receiving terminal 22 to the Internet server 32 and additional 
software is downloaded on a line 36 from the Internet server 32 to the receiving 
terminal 22. The receiving terminal 22 receives and installs the requested software as 

30 shown in a next step 60 following the software downloaded signal 36 sent to the 

receiving terminal 22 from the Internet server 32. Finally, in a step 62, the receiving 
terminal 22 renders the FMMS supported by the originally available or just installed 
software in the receiving terminal 22 and thus, the supported components (supported 
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components and unsupported components for which the additional software installed 
using the URLs) of the multimedia message are perceived 28 by the user 24. 

It should be realized that many variations of the above-described methodology 
are possible. For instance, the step 54 shown in Figure 2 could be broken down into 
5 two steps where the MSS and URL signals are sent separately or where the ordering 
of the illustrated steps is altered. Thus, the signal on the line 20 should be understood 
in that sense. Another example of variation is when the MMSC is a Web server. In 
that case, there is no sending terminal 10. The MMS 12 is a multimedia content (e.g. a 
Web page) stored in the MMSC 14. The receiving terminal 22 sends the message 
10 retrieval request signal 18 to the MMSC 14 to obtain the multimedia content. The 
MMSC 14, realizing that the terminal cannot support all components of the 
multimedia content but that terminal-specific software exist for solving the problem, 
sends the MMSS 20 containing the multimedia content and the URL signal supporting 
said software. 

1 5 Finally, the adaptation of the multimedia message does not need to take place 

in the MMSC 14 but can be performed in a separate server to which the MMSC 
requests message adaptation to be performed including inclusion of the earlier 
described URLs. Furthermore, in general the receiving terminal 22 can receive the 
MMSS 20 containing the FMMS and the URL signal from a different server and not 

20 necessarily form the MMSC 14. 



